На сайте проекта VMware Labs появилась запись о том, что утилита App Volumes Packaging Utility 1.3 теперь официально включена в состав VMware App Volumes 4, version 2103. Такое иногда происходит с утилитами проекта Labs, некоторые из которых становятся либо самостоятельными продуктами, либо включаются в состав уже существующих решений.
Напомним, что Packaging Utility позволяет упаковывать приложения для использования с App Volumes. С помощью нее можно добавить необходимые метаданные в приложение MSIX на базе дисков VHD таким образом, чтобы их можно было использовать вместе с пакетами формата AV. Получившиеся VHD формата MSIX будут требовать App Volumes 4 версии 2006 или более поздней, а также Windows 10 версии 2004 или более поздней.
Соответственно сам продукт App Volumes был обновлен, давайте посмотрим на его новые возможности:
Теперь при установке App Volumes Manager можно выбрать пункт "App Volumes Tools" при установке на машину с Windows 10, который и устанавливает Packaging Utility. Далее с помощью команды appcapture.exe можно упаковывать приложения без необходимости использования консоли App Volumes Manager. С помощью appcapture можно автоматизировать процессы упаковки приложений для установщиков в silent-режиме, которые можно получать как в VMDK, так и в VDH форматах (причем одновременно). С помощью appcapture можно конвертировать пакеты между форматами VHD and VMDK, а также работать с пакетами формата MSIX.
Теперь есть возможность использовать глобальную настройку, позволяющую использовать пакет на любой ОС Windows 10. В Advanced Settings можно поставить галочку, которая отключает проверку, что та же самая версия ОС использовалась для создания пакета и его доставки в рабочее окружение пользователя.
Интервал Import Storage Groups по умолчанию был увеличен с 15 минут до 4 часов, чтобы позволить задаче закончить обработку большого числа пакетов на медленных хранилищах. Этот параметр можно изменить в настройках.
На странице Managed Storage Locations хранилище может быть помечено как read-only. В этом случае App Volumes Manager пропускает это хранилище, когда обновляет пакет или AppStack. Так как App Volumes регулярно записывает дополнительные метаданные в пакеты, чтобы отслеживать их обновления, эта опция оказывается очень полезной для некоторых хранилищ.
Также была обновлена подсистема безопасности и исправлены ошибки.
Загрузить VMware App Volumes 4, version 2103 со встроенной утилитой App Volumes Packaging Utility 1.3 можно по этой ссылке.
Не так давно мы писали о механизме VMware vSAN Enhanced Durability, который позволяет еще больше защитить кластер хранилищ от аварий и сбоев, которые могут происходить не в один момент, а друг за другом на протяжении некоторого времени.
Дункан Эппинг рассказал о том, что происходит, если в нем всего три хоста. Например, если у вас есть 2 площадки, по три хоста ESXi на каждой, но в случае сконфигурированной политикии SFTT=1 (это Stretched FTT) у вас получается RAID-1 для дисковых объектов виртуальной машины на каждой из площадок:
При этом два хоста хранят в себе Data Component виртуальной машины, а третий хост работает для нее как Witness на случай изоляции одного из хостов кластера. Теперь возникает вопрос - а что произойдет с механизмом Enhanced Durability, если один из хостов перевести в Maintenance Mode? Где будет создаваться Durability Component (он хранит все поступающие операции записи Write IO), который защищает машину от сбоя на уровне площадки при переведенном в режим обслуживания хосте?
Ответ тут прост - этот компонент будет создаваться на других хостах, даже если он выполняет функции Witness (но, конечно же, он будет создан на хосте этой площадки):
Ну и небольшое демо процесса тестирования механизма Enhanced Durability в этих условиях от Дункана:
Таги: VMware, vSAN, HA, Storage, DR, Stretched Cluster
Компания StarWind, ведущий производитель программно-аппаратных решений для отказоустойчивых хранилищ под виртуальные машины, представила новое предложение - HCI Evaluation Kit для программно-аппаратных комплексов StarWind HyperConverged Appliance (HCA). С помощью набора для быстрого старта HCI Evaluation Kit вы сможете получить решение на базе вложенных (nested) виртуальных машин, в рамках которого будет работать sandbox-кластер...
В вышедшем на днях обновлении VMware vSphere 7 Update 2a (обновился только vCenter) компания VMware представила службу vSphere Virtual Machine Service (она же VM Service), которая дает разработчикам и администраторам, работающих со средой контейнеров Kubernetes в решении vSphere with Tanzu, возможности по развертыванию виртуальных машин.
Это позволит командам DevOps управлять инфраструктурой виртуальных машин и контейнеров через стандартные Kubernetes API, обеспечивая единый процесс по развертыванию новых служб и доступности инфраструктуры.
Служба VM Service дополняет ранее анонсированные службы Network Service и Storage Service, которые дают возможности по управлению через API сетью и хранилищем, соответственно, в среде vSphere with Tanzu. Вот хороший обзор новых функций VM Service:
Со стороны vSphere служба встроена напрямую в vCenter, она позволяет управлять образами ВМ (VM Images / Content Libraries) и классами ВМ (VM Classes / VM sizing).
Со стороны Kubernetes компонент называется VM Operator, он создает и обслуживает ресурсы Kubernetes Custom Resources (CRs/CRDs), а также общается с компонентом на стороне vSphere.
VM Service даст компаниям следующие преимущества:
Разработчикам в среде Kubernetes больше не требуется создавать заявки на создание ВМ для администраторов.
Администратор может преконфигурировать заданные классы ВМ, доступные разработчикам, задав лимиты их ресурсов, а также обеспечив защиту и изоляцию от продуктивного окружения.
Некоторые приложения в контейнерах, например, могут использовать базу данных, размещенную в ВМ. В этом случае разработчик сможет создать спецификацию такого сервиса в YAML и обслуживать такую структуру самостоятельно.
Open Source природа сервиса позволит дорабатывать и создавать новые службы с учетом потребностей больших команд. Репозиторий компонента VM Operator находится тут.
Более подробно о службе vSphere Virtual Machine Service рассказано в этой статье. Служба VM Service доступна в последнем релизе VMware vSphere 7 Update 2a.
Не так давно мы писали о новых возможностях средства для организации отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2. Среди новых возможностей мы упоминали поддержку служб vSAN File Services для растянутых кластеров (Stretched Clusters).
Дункан Эппинг раскрыл эту тему несколько подробнее. Действительно, службы vSAN File Services, так удобные для ROBO-сценариев при доступе к общим файловым шарам, теперь полностью поддерживаются.
Теперь в vSAN 7 U2 при настройке File Services надо указать, какому сайту принадлежит каждый из IP-адресов серверов файловых служб. Это Affinity rule, но оно не жесткое - при отказе виртуальных машин и рестарте их на другой площадке, оно может быть нарушено.
Но это еще не все. Для каждой файловой шары вам необходимо будет указать Affinity в ее настройках:
Это позволяет точно определить, файловую шару какой площадки следует использовать при соединении с ней клиентов. Опять-таки, это не строгое правило, на что намекает наличие опции "Either".
Ну и небольшой обзор работы файловых служб в растянутом кластере vSAN 7 Update 2 от Дункана:
Таги: VMware, vSAN, File Services, SMB, Storage, HA, Stretched
Все, кто хоть раз сталкивался с инфраструктурой виртуальных ПК VMware Horizon, знает, что в этом решении есть 3 способа развертывания виртуальных ПК для нужд различных типов пользователей. Делается это с помощью одного из следующих видов клонов:
Full Clone - полная копия родительской виртуальной машины, абсолютно никак с ней не связанная и действующая как полноценная новая ВМ.
Linked Clone - связанный клон виртуальной машины, создаваемый со стороны View Composer, который использует общее для всех клонов хранилище реплики на чтение, но имеет собственное хранилище для операций записи (дельта-диск или redo log). Память такой ВМ полностью независима от родительской ВМ, которая называется репликой (потому что она получается путем создания дубликата мастер-образа).
Instant Clone - это мгновенный клон работающей виртуальной машины, то есть имеющий с ней не только общее хранилище на чтение, но и общую память, для которой также используется техника copy-on-write. То есть это больше похоже на контейнерную виртуализацию.
Давайте теперь посмотрим на все эти виды клонов в деталях:
Full Clone
Это самый простой и понятный случай. С точки зрения производительности это всегда будет лучший вариант, так как это обычная виртуальная машина. Функциональность тут та же, что и для обычных ВМ. Очевидно, что главный минус - это скорость развертывания такой ВМ под новых пользователей, ведь нужно физически скопировать данные ее виртуальных дисков.
Но есть и еще некоторый минус по сравнению со связанными и мгновенными клонами - это обновления. Так как полные клоны содержат свою копию ОС, то вам нужно обновлять каждую машину, а не только реплику/родительскую ВМ, как в случае с Linked и Instant Сlones.
В целом, тут рассказывать особо больше не о чем, параметры производительности полного клона можно взять за эталон по отношению к остальным видам.
Linked Clone
Связанные клоны появились довольно давно в решении VMware View (тогда Horizon еще не было). Их созданием занимался и продолжает заниматься компонент VMware View Composer, который управляет процессами, связанными с развертыванием пулов виртуальных десктопов.
Суть таких клонов заключается в создании реплики от мастер-образа виртуального ПК, который подготовлен к массовому развертыванию (настроена ОС и установлены приложения). Реплика является родителем для новых виртуальных десктопов в плане их общего хранилища на чтение. Все операции чтения, которые создают клоны, складываются в отдельные дельта-диски за счет технологии copy-on-write, позволяющей при записи операции I/O перемещать ее в отдельный файл отличий от родительского диска.
Это очень удобно - такие десктопы создаются очень быстро (нужно только создать дельта-диски), реплика не должна быть включена и активна (только ее хранилище), а хранилище очень сильно экономится, ведь общие данные (предустановленные приложения и ОС) хранятся только в одном экземпляре. Такая модель идеально подходит для временных ПК - например, для сотрудников кол-центров, которые используют какое-то приложение во время работы (например, CRM), но в остальное время десктоп оказывается не нужен.
В этом случае, в соответствии с политикой пула Linked Clone, виртуальный ПК можно уничтожить после отключения пользователя или оставить висеть до следующего логина, а уничтожать после операции Log off. Что еще тут важно - к такому десктопу можно прицепить persistent-диск, который будет сохранять данные пользователя даже при выключении десктопа.
Недостатки тоже очевидны: инфраструктура связанных клонов опирается на компонент View Composer и зависит от его надежности, а операции записи и чтения работают медленнее, так как при записи данных нужно потратить ресурсы на обработку механизма copy-on-write, а при чтении - найти откуда данные считать - из базового образа или из дельта-дисков пользователей.
Тут надо обязательно отметить, что начиная с VMware Horizon 8 (2006), связанные клоны помечены как Deprecated-функционал, то есть вскоре (а именно, в следующей мажорной версии Horizon) будет произведен переход на мгновенные клоны, о которых рассказано ниже.
Instant Clone
Функция мгновенного клонирования виртуальной машины (ранее известная как технология VMFork) позволяет очень быстро сделать работающую копию запущенной ВМ на платформе VMware vSphere. Что важно, она не зависит от централизованного сервера, а реализована прямо на уровне гипервизора VMware ESXi. Появилась эта возможность в vSphere 6.7 и до сих пор совершенствуется.
Работает мгновенное клонирование так: посредством Memory copy-on-write "на лету" создается клон виртуальной машины (VMX-файл, процесс в памяти), который начинает использовать ту же память (Shared memory) на чтение, что и родительская ВМ. При этом дочерняя ВМ в общую память писать не может, а для записи и чтения собственных данных используется выделенная область памяти. Для дисков аналогично - с использованием технологии Copy-on-write в дельта-диск дочерней ВМ пишутся отличия от базового диска родительской ВМ:
Такой подход больше похож на контейнерную виртуализацию, где в рамках одной общей ОС работает несколько изолированных окружений - и это действительно так, со всеми его плюсами и минусами. Плюсом является экономия дискового пространства и памяти, а также скорость создания такого клона - он не просто быстрее создается, но и сразу включен и готов к использованию. Еще очевидным преимуществом является независимость технологии мгновенных клонов от сервисов View Composer, а значит в этом смысле надежность инфраструктуры таких ПК несколько выше.
Цикл включения нового десктопа для мгновенных клонов гораздо короче:
Минусы здесь те же самые, что и для связанных клонов, только добавляются ограничения по числу дочерних ВМ на одну родительскую, издержки на поддержание сложной системы работы с памятью (что влияет на безопасность и производительность), а также отсутствие поддержки некоторых функций.
Причина падения производительности ввода-вывода проста: у родительской ВМ создается дельта-диск, который используется первым мгновенным клоном, потом базовая ВМ несколько меняется за время до создания следующего - и на момент создания нового мгновенного клона будет использоваться уже следующий дельта-диск и так далее.
Такая схема имеет недостаток в том, что у родительской ВМ плодятся дельта-диски, что приводит к тому, что быстродействие родительской ВМ замедляется, а сама структура за счет увеличения числа дисков существенно усложняется, что потенциально может привести к различного рода сбоям.
Сейчас для связанных клонов недоступны следующие возможности:
Кастомизация машин средствами Sysprep и Quickprep
ОС Windows 8 и 8.1
Функции Persona Management
Тома Virtual Volumes (VVols)
Нативные снапшоты на хранилищах через VAAI (vStorage APIs for Array Integration)
Указание имен компьютеров ВМ вручную (это доступно для связанных клонов в пулах dedicated- или floating-)
Политика питания Remote machine power policy (Always Powered On, Suspend, Power Off) для пула
Привязка постоянных (Persistent) дисков
Несмотря на то, что персистентные диски не работают из коробки для связанных клонов, эту проблему можно решить с помощью продуктов Dynamic Environment Manger DEM , Microsoft FSLogix или VMware App Volumes Writable Volumes.
У компании VMware есть прекрасный документ "Understanding Clones in VMware vSphere 7", где описываются результаты тестирования производительности всех трех типов клонов. Очень интересный whitepaper, давайте взглянем на некоторые выводы в нем содержащиеся.
Первое - это скорость развертывания клонов и тестирование производительности под большой нагрузкой ввода-вывода:
Очевидно, что связанные и мгновенные клоны создаются намного быстрее полных ввиду своей природы. Мгновенные создаются несколько дольше связанных из-за того, что первым нужно время не только на настройку операций copy-on-write с диском, но и с памятью.
А вот правая часть картинки показывает нам, насколько падает производительность подсистемы ввода-вывода при тяжелых нагрузках - для связанных клонов больше, чем в три раза, а для мгновенных - аж в четыре (Hammer DB создает нагрузку еще и на память, которую должен обслуживать механизм мгновенных клонов).
Второй не менее интересный тест - с помощью методики SPECjbb. Тут брали не машины с хранилищем 450 ГБ и тяжелой нагрузкой по вводу-выводу, как в прошлом тесте, а легковесные машины с 16 ГБ диска и нагрузку делали на CPU и память. Результат получился таким:
Первый важный вывод - самое большое время на развертывание связанные и мгновенные клоны тратят в самом начале, уступая для маленьких машин полным клонам, но потом полные клоны долго завершают копирование данных виртуальных дисков.
Второй полезный инсайт - с точки зрения отработки запросов к CPU и памяти (а именно это и меряет SPECjbb) все три типа клонов ведут себя одинаково в пределах статистической погрешности в 5%.
Следующая картинка - влияние на родительскую ВМ. Очевидно, что для полных клонов влияния никакого нет, а вот для связанных и, тем более, мгновенных клонов влияние большое:
И, опять-таки, для памяти и CPU связанных и мгновенных клонов такого влияния практически нет.
Следующая картинка - развертывание полного клона по сети на другой хост ESXi. Для мгновенных клонов такая возможность отсутствует, а для связанных требуется общее хранилище. Мы тут видим, как сильно увеличивается время развертывания полного клона по сети:
При увеличении числа виртуальных машин совокупная производительность по вводу-выводу растет вот так:
При увеличении числа клонов картина для CPU/памяти вполне ожидаемая:
С точки зрения CPU все три вида клонов будут работать одинаково, а вот с точки зрения памяти - мгновенные клоны будут немного помедленнее, так как некоторое количество ресурсов тратится на обслуживание работы механизма работы с памятью.
Что касается времени развертывания разного количества для трех типов клонов, тут тоже все понятно: полные клоны растут линейно, остальные - несущественно.
Итоги
Давайте сведем теперь в простую таблицу все преимущества и недостатки полных, связанных и мгновенных клонов, чтобы это могло помочь вам выбрать нужную схему использования виртуальных ПК:
Преимущества
Недостатки
Full Clone
Быстродействие по вводу-выводу
Нет зависимости от родительской ВМ
Высокая надежность, нет единой точки отказа для нескольких ПК
Возможность удаленного клонирования на любой хост без общего хранилища
Долгое время развертывания и подготовки для пользователя
Отсутствие экономии пространства (каждый десктоп имеет полностью свое хранилище)
Нельзя использовать операции быстрого создания и уничтожения десктопа
Медленный накат обновлений (нужно обновлять каждый десктоп)
Linked Clone
Экономия дискового пространства за счет одной копии данных на чтение
Быстрое создание и уничтожение клона
Быстрый накат обновлений на реплику и обновление существующих и новых десктопов (Rebuild/Refresh)
Падение производительности хранилища из-за снапшотов/дельта-дисков и поиска данных при чтении и записи
Зависят от служб View Composer
Помечены как Deprecated, в будущих релизах будут отсутствовать
Instant Clone
Десктоп создается мгновенно и сразу готов к работе (клон от работающей машины)
Нет зависимости от служб Composer/vCenter
Быстрое обновление ОС
Экономия не только диска, но и памяти
Дополнительный уровень сложности и отказа - не только общий диск, но и память родительской ВМ
Низкая производительность хранилищ по вводу-выводу
Нельзя использовать некоторые возможности платформы
Нельзя использовать persistent-хранилища без дополнительного ПО
Недавно мы писали о новых возможностях решения для создания отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2. Среди новых функций мы упоминали возможность Enhanced Data Durability, позволяющую еще больше защитить кластер хранилищ от аварий и сбоев, которые могут происходить не в один момент, а друг за другом на протяжении некоторого времени.
Как знают администраторы vSAN, этот продукт обеспечивает высокую степень защиты данных от сбоев, в том числе встроенным механизмом избыточности, регулируемым политикой FTT (Failures to tolerate).
Однако при отказе одного или нескольких хостов ESXi в кластере vSAN может произойти ситуация, когда дисковый объект есть на одном из хостов, но только в одном экземпляре. Такая ситуация опасна тем, что если произойдет второй сбой, затрагивающий этот объект - данные могут быть безвозвратно утеряны.
Кстати, при переводе хоста в плановый режим обслуживания такая ситуация тоже может возникнуть - но в vSAN этот момент учитывался и раньше, и на время обслуживания все операции записи сохранялись до момента возвращения хоста в строй, после чего происходило накатывание операций, случившихся за это время:
Теперь же такой механизм появился и для внештатных ситуаций:
При сбое и недоступности хранилищ хост ESXi, который понял, что произошла авария, начинает записывать дельта-данные дискового объекта с этого момента не только на хранилище, где хранится активная реплика, но и в дополнительное хранилище (durability component), чтобы обеспечить надежность данных, записываемых во время сбоя.
По умолчанию в случае сбоя кластер vSAN ждет 60 минут до начала восстановления дискового объекта на другом хранилище хоста ESXi для обеспечения политики FTT. Это связано с тем, что кластер не начинает емкие по ресурсам операции для сбоев, которые могут оказаться временными. Регулируется это настройкой Object Repair Timer (она же настройка vsan.clomrepairdelay в Advanced Settings, подробнее об этом тут):
Если в этот момент случится еще одна авария, которая затронет единственно выжившую копию данных, то виртуальная машина остановится, но возможность восстановить данные будет - как только хост с последней копией данных восстановится, на них накатятся сохраненные инкрементальные операции записи. Это позволит получить состояние виртуальной машины без потери всех последних операций записи.
Надо сказать, что операции по созданию durability component имеют приоритет над стандартными операциями vSAN, такими как синхронизация дисковых объектов, поэтому это происходит очень быстро, чтобы сразу начать записывать дельта-writes. Операции записи в durability component будут продолжаться (он будет в состоянии active), пока синхронизация дискового объекта с его репликой не завершится удачно (либо на восстановившемся хосте, либо на новом, после операции rebuild). После этого durability component для дискового объекта будет удален.
Еще стоит отметить, что если хост с durability component откажет, то новый хост возьмет на себя его функции и создаст свой durability component (число таких операций не ограничено). Также полезно то, что защита данных с помощью durability component работает и для дисковых объектов с FTT=2 или выше - главное, чтобы у вас было для всех этих операций свободное дисковое пространство в кластере.
На днях мы писали о новых возможностях решения для создания отказоустойчивых хранилищ VMware vSAN 7.0 Update 2. Дункан Эппинг обратил внимание на один из вспомогательных сервисов - VMware Skyline Health, в котором появилось очень полезное нововведение - Health History.
Теперь в сервисе Skyline Health (ранее он назывался Health Check) появилась опция по визуализации пройденных / не пройденных проверок для различных объектов в исторической ретроспективе, которая позволит вам соотнести непройденные проверки с происходившими странностями, ошибками или отказами компонентов инфраструктуры:
Вы можете вернуться до 30 дней назад во времени, указав промежуток, в котором вы хотите посмотреть детали непройденных или успешных проверок. Опцию сохранения этих данных можно отключить на вкладке Configuration.
При клике на красный квадрат, вы можете увидеть какие именно проверки не были пройдены, а также для скольки объектов они прошли успешно, а для скольки нет:
Ну и посмотрите небольшое видео от Дункана, где он показывает, как это работает в его тестовой лаборатории:
Недавно мы писали о новых возможностях обновленной платформы виртуализации VMware vSphere 7 Update 2, а также новой версии средства создания отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2. Сегодня мы немного подробнее расскажем о новых возможностях инфраструктуры работы с хранилищами (core storage) в новом обновлении vSphere.
Давайте посмотрим, что именно там нового:
1. Увеличение iSCSI Path Limit
Раньше для одного LUN максимально доступны были только 8 путей, но многим пользователям требовалось существенно больше. Используя несколько портов VMKernel или точек назначения, пользователям иногда было нужно 16 или даже 24 пути. Теперь максимум составляет 32 пути на LUN, что должно хватить всем.
2. Поддержка RDM для RHEL HA
Теперь для для работы Red Hat Enterprise HA можно использовать тома RDM на платформе vSphere. В корневых механизмах работы с хранилищами для этого были сделаны некоторые изменения.
3. Улучшения снапшотов VMFS SESparse
При чтении данных для машин со снапшотами существенно увеличилась производительность, так как чтение идет сразу из нужного VMDK, минуя всю цепочку снапшотов при каждом обращении, в отличие от того, как это было сделано раньше. Все это снижает latency на чтение.
4. Поддержка нескольких адаптеров Paravirtual RDMA (PVRDMA)
В vSphere 6.7 была анонсирована поддержка RDMA. Одним из ограничений было то, что для одной виртуальной машины можно было использовать только один адаптер PVRDMA. Теперь этой проблемы больше нет.
5. Улучшения производительности для томов VMFS
Здесь были сделаны улучшения первых операций чтения для тонких дисков. Они особенно проявляются при резервном копировании и восстановлении, операциях копирования данных и Storage vMotion.
6. Улучшения работы с NFS-хранилищами
Теперь не обязательно создавать клон ВМ для использования offload'а операций по созданию снапшотов уровня дискового массива. Теперь можно использовать любые виртуальные машины на базе снапшотов без необходимости создавать redo logs.
7. Поддержка High Performance Plugin FastPath для Fabric Devices
Плагин HPP теперь используется по умолчанию для устройств NVMe. В плагине есть 2 опции - SlowPath для legacy-поведения и новый FastPath для большей производительности, но с некоторыми ограничениями. Подробнее рассказано вот в этой статье.
8. HPP - дефолтный плагин для vSAN
Начиная с vSphere 7 Update 2, HPP теперь дефолтный MPP для всех устройств - SAS/SATA/NVMe (и Fabric Devices, как было сказано выше).
9. Улучшения VOMA
Средство vSphere On-disk Metadata Analyzer (VOMA) используется для нахождения и исправления повреждений метаданных томов, которые влияют на файловую систему и логические тома. Теперь это доступно и для spanned VMFS-томов. Более подробно об этом можно узнать тут.
10. Поддержка бОльших значений Queue Depth для vVols Protocol Endpoints
В некоторых случаях параметр Disk.SchedNumReqOutstanding (DSNRO) не соответствует глубине очереди на vVols Protocol Endpoint (PE) (он же VVolPESNRO). Теперь глубина очереди для PE равна 256 или берется максимальная глубина видимого LUN. Поэтому минимум PE QD выставлен в 256.
11. Создание Config vVol больше, чем на 4 ГБ
Теперь это позволяет партнерам VMware хранить образы для автоматических билдов на томах VVols.
12. Улучшения правил SPBM Multiple Snapshot
Движок Storage Policy Based Management позволяет администратору управлять фичами хранилищ VVols на уровне отдельных виртуальных машин. Теперь в рамках одной политики SPBM можно использовать несколько правил для снапшотов (например, интервалы их создания). Эта фича должна поддерживаться на уровне VASA у соответствующего производителя массива.
13. Поддержка снапшотов для Cloud Native Storage (CNS) на базе First Class Disks
Тома Persistent Volumes (PV) на платформе vSphere создаются как First-Class Disks (FCD). Это независимые диски без привязанных к ним ВМ. Для них теперь есть поддержка снапшотов и их можно делать в количестве до 32 штук. Это позволяет делать снапшоты ваших K8s PV на платформе vSphere Tanzu.
14. Маппинг CNS PV на vVol
В некоторых случаях пользователи хотят видеть, какие тома VVols ассоциированы с томами CNS Persistent Volume (PV). Теперь этот маппинг можно увидеть в интерфейсе CNS.
Вчера мы писали о новых возможностях обновленной платформы виртуализации VMware vSphere 7 Update 2, а сегодня расскажем о вышедшем одновременно с ней обновлении решения для создания отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2.
Нововведения сосредоточены в следующих областях:
Давайте посмотрим, что именно нового в vSAN 7 U2:
Улучшения масштабируемости
HCI Mesh Compute Clusters
Теперь в дополнение к анонсированной в vSphere 7 Update 1 топологии HCI Mesh для удаленного доступа к хранилищам vSAN появилась технология HCI Mesh Compute Clusters, которая позволяет иметь вычислительный кластер vSphere/vSAN без собственных хранилищ, использующий хранилища удаленных кластеров.
Самое интересное, что эти кластеры не нуждаются в лицензиях vSAN, вы можете использовать обычные лицензии vSphere.
Также такие кластеры vSAN могут использовать политики хранилищ, в рамках которых можно получить такие сервисы, как дедупликацию / компрессию или шифрование Data-at-rest:
Также было увеличено число хостов ESXi, которые могут соединяться с удаленным датастором, до 128.
Небольшое видео о том, как создать HCI Mesh Compute Cluster:
Улучшение файловых служб
Службы vSAN file services теперь поддерживают растянутые (stretched) кластеры и двухузловые конфигурации, что позволяет использовать их для ROBO-сценариев.
Улучшения растянутых кластеров
Растянутые кластеры vSAN теперь обрабатывают не только различные сценарии сбоев, но и условия восстановления, которые были определены механизмом DRS до наступления события отказа. DRS будет сохранять ВМ на той же площадке до того, как данные через inter-site link (ISL) будут полностью синхронизированы после восстановления кластера, после чего начнет перемещать виртуальные машины в соответствии со своими правилами. Это повышает надежность и позволяет не загружать ISL-соединение, пока оно полностью не восстановилось.
Технология vSAN over RDMA
В vSAN 7 Update 2 появилась поддержка технологии RDMA over Converged Ethernet version 2 (RCoEv2). Кластеры автоматически обнаруживают поддержку RDMA, при этом оборудование должно находиться в списке совместимости VMware Hardware Compatibility Guide.
Улучшения производительности
В vSAN 7 U2 была оптимизирована работа с RAID 5/6 в плане использования CPU. Также была улучшена производительность яруса буффера. Это позволяет снизить CPU cost per I/O.
Кроме того, были сделаны оптимизации для процессоров AMD EPYC (см. тут).
Улучшения для задач AI and Developer Ready
Здесь появилось 2 основных улучшения:
S3-совместимое объектное хранилище для задач AI/ML и приложений Cloud Native Apps.
На платформе vSAN Data Persistence platform теперь поддерживаются компоненты Cloudian HyperStore и MinIO Object Storage. Пользователи могут потреблять S3-ресурсы для своих AI/ML нагрузок без необходимости долгой настройки интеграций.
Улучшения Cloud Native Storage в vSphere и vSAN
Теперь Cloud Native Storage лучше поддерживает stateful apps на платформе Kubernetes. Также vSAN предоставляет простые средства для миграции с устаревшего vSphere Cloud Provider (vCP) на Container Storage Interface (CSI). Это позволит иметь персистентные тома Kubernetes на платформе vSphere и расширять их по мере необходимости без прерывания обслуживания.
Улучшения безопасности
Службы vSphere Native Key Provider Services
Это механизм, который позволяет использовать защиту data-at-rest, такую как vSAN Encryption, VM Encryption и vTPM прямо из коробки. Также для двухузловых конфигураций и Edge-топологий можно использовать встроенный KMS-сервис, который работает с поддержкой ESXi Key Persistence.
Средства для изолированных окружений
VMware предоставляет Skyline Health Diagnostics tool, который позволяет самостоятельно определить состояние своего окружения в условиях изоляции от интернета. Он сканирует критические компоненты на проблемы и выдает рекомендации по их устранению со ссылками на статьи базы знаний VMware KB.
Улучшения Data In Transit (DIT) Encryption
Здесь появилась валидация FIPS 140-2 криптографического модуля для DIT-шифрования.
Упрощение операций
Улучшения vLCM
Для vSphere Lifecycle Manager появились следующие улучшения:
vLCM поддерживает системы Hitachi Vantara UCP-HC и Hitachi Advanced Servers, а также серверы Dell 14G, HPE10G и Lenovo ThinkAgile.
При создании кластера можно указать образ существующего хоста ESXi.
Улучшения защиты данных
При сбое и недоступности хранилищ хост ESXi, который понял, что произошла авария, начинает записывать дельта-данные с этого момента не только на хранилище, где хранится активная реплика, но и в дополнительное хранилище, чтобы обеспечить надежность данных, создаваемых во время сбоя. Ранее эта технология применялась для запланированных операций обслуживания.
Поддержка Proactive HA
vSAN 7 Update 2 теперь поддерживает технологию Proactive HA, которая позволяет проактивно смигрировать данные машин на другой хост ESXi.
Улучшения мониторинга
Здесь появились новые метрики и хэлсчеки, которые дают больше видимости в инфраструктуре коммутаторов, к которой подключены хосты vSAN. На физическом уровне появились дополнительные метрики, такие как CRC, carrier errors, transmit и receive errors, pauses. Также для новых метрик были добавлены health alarms, которые предупредят администратора о приближении к пороговым значениям.
Улучшения vSphere Quick Boot
Здесь появилась техника ESXi Suspend-to-Memory, которая позволяет еще проще обновлять хосты ESXi. Она доступна в комбинации с технологией ESXi Quick Boot. Виртуальные машины просто встают на Suspend в памяти ESXi, вместо эвакуации с хоста, а потом ядро гипервизора перезапускается и хост обновляется.
Скачать VMware vSAN 7 Update 2 в составе vSphere 7 Update 2 можно по этой ссылке. Release Notes доступны тут.
Бонус-видео обзора новых фичей от Дункана Эппинга:
Таги: VMware, vSAN, Update, ESXi, vSphere, Storage, HA, DR, VMachines
Недавно компания Veeam Software, производитель лучших решений для обеспечения доступности виртуального датацентра, выпустила обновление платформы Veeam Cloud Data Management Platform, в состав которой входит самое известное решение для защиты виртуальных сред - Veeam Backup and Replication v11. Мы уже писали об RTM-релизе этого продукта, где вкратце рассказывали его новых возможностях, а сегодня разберем их подробнее.
Итак, собственно основные новые возможности Veeam Backup and Replication v11 (наш топ-15):
1. CDP : Continuous Data Protection
Эта технология позволяет настроить непрерывную защиту виртуальных машин средствами репликации таким образом, чтобы соблюдать заданные политики RPO (Recovery Point Objectives). Достигается это за счет использования технологии VMware VAIO (vSphere API for I/O filtering).
Для этого на хосты ESXi ставится специальный VIB-пакет (фильтр VAIO), который в режиме драйвера привязывается к нужным ВМ.
При создании CDP-политики вы задаете время в секундах, за которое вы можете себе позволить потерять данные в случае сбоя (RPO):
Short-term реплики будут crash-консистентными, а long-term можно уже настроить как Application-aware, чтобы быть уверенным в работоспособности приложений виртуальной машины в конкретной точке в прошлом.
2. Функции асинхронного процессинга
В Veeam v11 при чтении данных с репозиториев происходит их асинхронный процессинг. Это ускоряет процесс для Enterprise-оборудования, но может быть неудобно для недорогих систем хранения, поэтому эту опцию можно отключить в реестре.
3. Возможность Backup Copy Retention
Политика хранения задач Backup copy job теперь имеет такую же логику, как и primary backup job - то есть GFS (Grandfather-Father-Son).
4. Улучшенная работа с тэгами vSphere
Теперь вы можете использовать оператор AND для добавления условия по комбинациям тегов при поиске и создании задач.
5. Представления избранных фильтров
Теперь представление с избранными фильтрами есть в управляющем дереве наравне с самими фильтрами.
6. Защищенный Linux-репозиторий
Возможность создания на Linux-репозиториях бэкапов, которые нельзя удалить (immutability), в целях защиты от вредоносных действий, который может предпринять злоумышленник, заметая следы (также это очень полезно в борьбе с Ransomware, когда может возникнуть ситуация, что вас нет рабочих систем, а бэкапы удалены). Кроме того, это может защитить от намеренной порчи данных изнутри организации.
Очень подробно об этой возможности на русском языке рассказано тут. Эта технология, по аналогии с Instant VM Recovery, позволяет быстро восстановить поврежденную или удаленную базу данных MS SQL из резервной копии. Для этого надо зайти в Restoring Application Items -> Microsoft SQL Server. Далее в Veeam Explorer для нужной базы нужно выбрать опцию Instant Recovery.
Работает сама технология по такой схеме:
8. Возможность восстановления файлов Linux без необходимости развертывания виртуального модуля Helper Appliance
Теперь вам не нужно развертывать эти виртуальные модули, чтобы иметь возможность быстро восстанавливать файлы на Linux. Бэкап можно примонтировать к любой Linux-машине напрямую. Теперь восстановление будет работать быстрее, так как не нужно тратить время на развертывание helper appliance.
Отдельные файлы можно восстанавливать также и в системах IBM AIX, MAC и Oracle Solaris.
9. Улучшенные режимы Linux Backup Proxy
Теперь можно использовать не только методику hot-add, как было в 10-й версии, но и другие режимы (Network Mode, Direct SAN с NFS, iSCSI и FC, а также бэкап из снапшотов хранилищ).
10. Улучшения по программе Veeam Cloud Service Provider
Технология CDP Low second RPO replication, которая позволяет улучшить показатели репликации за счет использования интерфейса vSphere APIs for IO (VAIO).
VCD to VCD Replication – функция для провайдеров VCSP, которая позволяет реплицировать данные между организациями VMware Cloud Director для одного или разных инстансов VCD.
VCD Native HTML5 Plugin - vCloud Director Self Service Portal интегрирован напрямую в VCD.
Улучшенная поддержка объектных хранилищ, в частности появилась поддержка Google Storage.
11. Улучшения Veeam Service Provider Console v5
Новая версия консоли Veeam Service Provider Console v5 даст сервис-провайдерам следующие возможности:
Готовая к производственной эксплуатации третья версия API
Новые возможности контроля над агентами для Windows, Linux и Mac
Возможность управлять бэкапами на AWS и Azure через обновленные нативные плагины
Улучшенные функции безопасности и новые интеграции
12. Модуль PowerShell для Veeam Backup and Replication
Теперь есть интегрированный модуль PowerShell 6.0, который устанавливается по умолчанию. Он позволяет управлять инфраструктурой резервного копирования на базе решений Veeam с помощью сценариев. Также в одиннадцатой версии Veeam B&R появилось 184 новых командлета.
13. Новый Rest API для Veeam Backup and Replication
Теперь Rest API есть не только в Veeam Backup Enterprise Manager, но и непосредственно на бэкап-серверах, что существенно увеличивает гибкость выполнения задач и построения новых интеграций через API.
14. Поддержка Amazon S3 Glacier и Microsoft Azure Archive Storage
Теперь администраторы могут использовать сервисы хранилища Amazon S3 Glacier (включая Glacier Deep Archive) и Microsoft Azure Archive Storage для обеспечения полного цикла облачного хранения резервных копий.
15. Расширение поддержки объектных хранилищ
Теперь можно использовать Google Cloud Storage (GCS) как объектное хранилище за счет нативной интеграции GCS через собственный API Veeam.
Backup & Replication v11 содержит новые версии Veeam ONE v11 (11.0.0.1379), а также апдейт Agent for Windows (5.0.0.4300) и Linux (5.0.0.4318), плюс совершенно новые Mac Agent (1.0.0.713) и Veeam Service Provider Console (5.0.0.6726). Про агенты можно подробно прочитать на русском языке вот тут.
Полный список новых возможностей приведен в документе Veeam v11 What's New (всего их более 200), в котором они занимают аж 21 страницу. Скачать новую версию этого продукта можно по этой ссылке.
Продолжаем рассказывать о лучшем в отрасли решении для создания программных хранилищ под виртуальные машины на базе хост-серверов ESXi - StarWind Virtual SAN for vSphere. Как многие знают, с какого-то момента StarWind стала поставлять свое решение для платформ VMware в виде виртуального модуля (Virtual Appliance) на базе Linux, который реализует основные сервисы хранения, дедупликации и компрессии, а также отказоустойчивости и обеспечения надежности данных в виртуальных машинах.
Для виртуального модуля StarWind работа механизма дедупликации и компрессии обеспечивается средствами Linux-движка Virtual Data Optimizer (VDO), который появился относительно недавно. Это удобный и надежный способ экономии дискового пространства за счет использования дополнительных емкостей оперативной памяти на хосте.
Для начала вам нужно определиться с оборудованием хостов ESXi, где вы будете развертывать виртуальные модули StarWind. Как вы понимаете, в целях обеспечения отказоустойчивости таких узлов должно быть как минимум два.
Что касается HDD и SSD-дисков, то нужно также спланировать конфигурацию RAID на хранилище хостов. Сделать это можно в соответствии с рекомендациями, описанными в базе знаний StarWind. Вы можете использовать программный или аппаратный RAID, о настройках которого мы расскажем ниже.
Что касается дополнительной оперативной памяти на хосте ESXi, то нужно выбирать ее объем, исходя из следующих критериев:
370 МБ плюс дополнительные 268 МБ на каждый 1 ТБ физического хранилища
Дополнительно 250 МБ на 1 ТБ физического хранилища, если включена дедупликация (UDS index)
То есть для 4 ТБ физического хранилища с дедупликацией вам понадобится:
370 MB + 4 * 268 MB +4 * 250 MB = 2 442 MB RAM
Итого 2,4 ГБ оперативной памяти дополнительно к памяти под ОС виртуального модуля. Вообще, StarWind рекомендует 8 ГБ памяти для виртуального модуля - 4 ГБ на машину и 4 ГБ на движок VDO для работы с хранилищем.
Один VDO-том может работать с хранилищем до 256 ТБ, что покрывает максимум потребностей в рамках хранилищ на базе серверов. Также StarWind очень рекомендует использовать дисковые массивы All-flash или NVMe-оборудование.
Общее правило развертывания таких хранилищ таково:
Под VDO: аппаратный или программный RAID (LVM или mdraid)
Над VDO: "толстые" (thick) диски StarWind Virtual SAN в режиме stand-alone или HA
Надо понимать, что сам том VDO - это тонкий диск, растущий по мере наполнения, поэтому устройство под ним должно иметь расширяемую природу (MD RAID, LVM).
Примерная схема отказоустойчивого решения StarWind Virtual SAN for vSphere на базе 2 узлов выглядит так:
После того, как вы установите StarWind Virtual SAN, настроите виртуальную машину и StarWind Management Console, нужно будет настроить аппаратный или программный RAID для хранилища.
Если вы используете аппаратный RAID, то просто создайте виртуальный диск для ВМ StarWind Virtual SAN на его хранилище, но обязательно типа "Thick Provisioned Eager Zeroed" (также вы можете использовать RDM-диск):
Если же вы будете использовать программный RAID, то нужно будет использовать HBA или RAID-контроллер в режиме DirectPath I/O passthrough, чтобы получить прямой доступ к дискам и собрать на их базе RAID-массив.
Для этого вам нужно будте выбрать правильный HBA/RAID-контроллер как PCI-устройство:
И пробросить его напрямую в виртуальную машину StarWind:
После этого в StarWind Management Console можно будет собрать RAID нужного вам уровня:
Рекомендации тут такие:
После этого в виртуальном модуле StarWind на полученном хранилище нужно будет создать VDO-устройство с нужными вам параметрами:
Здесь мы видим, что создается устройство с включенной дедупликацией, выключенной компрессией, нужным размером индексной памяти и заданного объема.
После создания это устройство надо отформатировать в XFS со следующими параметрами:
Далее вы можете создавать хранилище StarWind на этом устройстве и (опционально) сделать его реплику на партнерском узле в режиме HA. Также рекомендуется выставить настройку Disk.DiskMaxIOSize на хосте ESXi
В значение 512:
Ну и про оптимизацию производительности I/O-планировщика прочитайте вот эту статью базы знаний StarWind. Если вам интересен процесс создания хранилищ с дедупликацией и компрессией на базе StarWind Virtual SAN в стиле "от и до", то рекомендуем прочитать вот эту статью.
Команда PowerCLI компании VMware на днях выпустила обновление средства vSphere Desired State Configuration (DSC) версии 2.2. Механизм DSC есть в экосистеме Windows, начиная еще с Windows Server 2012 R2. С помощью него можно мониторить и управлять конфигурациями систем посредством специальных конфигурационных файлов на базе PowerShell, которые имплементируются через движок Local Configuration Manager (LCM), который должен быть на каждом хосте.
У VMware этот механизм работает несколько иначе, в качестве LCM используется прокси-хост, поскольку LCM не запустить ни на vCenter Server Appliance, ни на ESXi:
Так работал механизм до текущего момента, когда пользователям приходилось разворачивать отдельную Windows-машину под LCM. Но теперь появился модуль VMware.PSDesiredStateConfiguration, который предоставляет пользователям набор командлетов, чтобы скомпилировать и исполнить конфигурацию DCS без использования DSC Local Configuration Manager. Это позволяет использовать как Windows, так и Linux-машину в качестве прокси.
При этом пользователям по-прежнему предоставляется возможность использовать как vSphereDSC с движком PowerShell LCM, так и модуль VMware.PSDesiredStateConfiguration.
Давайте посмотрим, что нового появилось в DCS версии 2.2:
1. Новые ресурсы PowerCLI модуля
Вот они:
DatastoreCluster - создание, изменение, апдейт или удаление Datastore cluster
3. Операция Install/Update для модуля VMware vSphereDSC
Установка модуля теперь делается так:
Install-Module -Name VMware.vSphereDSC
Обновление вот так:
Update-Module -Name VMware.vSphereDSC
4. Новый модуль VMware.PSDesiredStateConfiguration
Как было сказано выше, теперь вы можете использовать Windows или Linux-машину без LCM для использования механизма DCS. Установить модуль можно следующей командой:
Новый командлет New-VmwDscConfiguration создает объект VmwDscConfiguration, который содержит информацию о конфигурации. Эту конфигурацию можно задать в ps1-файле и передать ее данному командлету. Например:
С помощью vSphere Node можно указать объект VINode (сервер vCenter или хост ESXi) и применить соответствующую конфигурацию к нужному узлу vSphere. Это дает следующие возможности:
Персистентные сессии
Раньше для каждого подключения каждый ресурс требовал параметров учетной записи для установки сессии VISession. Теперь же если вы используете Vmware.PSDesiredStateConfiguration то можно создать персистентную VISession, которую можно использовать для всех ресурсов DCS.
Не нужны файлы MOF
Поскольку LCM теперь не используется, то и для командлета New-VmwDSCconfiguration они не требуются. Конфигурация может храниться в переменной, либо в ps1-файле.
Скачать VMware vSphere DSC 2.2 можно по этой ссылке.
Казалось бы, совсем недавно мы писали о выходе Veeam Availability Suite v10, в состав которого входил Veeam Backup & Replication 10, а компания Veeam выпускает уже одиннадцатую версию. Но нет, прошло уже больше года! Поэтому вполне вовремя видеть Veeam Backup & Replication 11, который вступил в стадию RTM-релиза (то есть продукт стал уже доступен для партнеров Veeam).
Пока в блогах Veeam вы можете почитать, что там появилось нового в целом, а после выхода мы расскажем подробности о главных возможностях продукта:
Обратная совместимость и поддержка платформы Veeam
Veeam Backup & Replication, начиная с версии 9.5 Update 4 (build 9.5.4.2866), может сохранять бэкапы через Cloud Connect в облачный репозиторий, включая таковой для версии v11.
Для репликации Cloud Connect Replication, реплики на основе Pre vCloud Director Hardware Plan могут отбрасываться на облачный хост v11.
Backup & Replication v11 содержит новые версии Veeam ONE v11 (11.0.0.1379), а также апдейт Agent for Windows (5.0.0.4300) и Linux (5.0.0.4318), плюс совершенно новые Mac Agent (1.0.0.713) и Veeam Service Provider Console (5.0.0.6726).
Улучшения Veeam Cloud Service Provider
Технология CDP Low second RPO replication, которая позволяет улучшить показатели репликации за счет использования интерфейса vSphere APIs for IO (VAIO).
VCD to VCD Replication – функция для провайдеров VCSP, которая позволяет реплицировать данные между организациями VMware Cloud Director для одного или разных инстансов VCD.
VCD Native HTML5 Plugin - vCloud Director Self Service Portal интегрирован напрямую в VCD.
Улучшенная поддержка объектных хранилищ, в частности появилась поддержка Google Storage.
Текущие лицензии на Veeam Backup & Replication v10 будут действовать и на одиннадцатую версию - получать новые лицензии вам не потребуется.
Улучшения Veeam Service Provider Console v5
Новая версия консоли Veeam Service Provider Console v5 даст сервис-провайдерам следующие возможности:
Готовая к производственной эксплуатации третья версия API
Новые возможности контроля над агентами для Windows, Linux и Mac
Возможность управлять бэкапами на AWS и Azure через обновленные нативные плагины
Улучшенные функции безопасности и новые интеграции
Более подробно о новом релизе Veeam Backup & Replication 11 рассказано на специальной странице вот тут, а в блоге Veeam вы можете найти статьи об отдельных функциях продукта. Официальный запуск новой версии платформы для резервного копирования и репликации состоится через 5 дней.
Многие администраторы VMware vSphere знают, что для организации кластеров Windows Server Failover Clusters (WSFC) нужен эксклюзивный доступ к LUN, а значит на уровне виртуальной инфраструктуры подходили только RDM-диски. Ранее эти кластеры назывались MSCS, мы писали об их организации в виртуальной среде вот тут.
Такая ситуация была из-за того, что WSFC использует механизм резервация SCSI-3 Persistent Reservations, который координирует доступ к общему дисковому ресурсы. С другой стороны, VMFS использует собственный механизм блокировки LUN, поэтому команды WSFC перехватываются и отменяются, если используются диски VMDK. Поэтому RDM-устройства и использовались как средство маппинга дисков виртуальных машин к физическому устройству LUN.
Оказывается, ситуация поменялась с выпуском VMware vSphere 7, где появился механизм Clustered VMDK. Он позволяет командам SCSI3-PR выполняться и применяться к виртуальному диску VMDK, поэтому вам не нужен отдельный LUN.
К сожалению, все это работает только на хранилищах Fibre Channel.
Чтобы это начать использовать, на уровне датастора надо установить параметр "Clustered VMDK Supported":
Далее нужно понимать следующие условия и ограничения:
Параметр кластера Windows Cluster "QuorumArbitrationTimeMax" должен быть выставлен в значение 60.
LUN за этим датастором должен поддерживать команды ATS SCSI (как правило, это всегда поддерживается).
LUN должен поддерживать резервации типа Write Exclusive All Resgistrants (WEAR).
VMDK-диски должны быть типа Eager Zeroed Thick и виртуальные машины должны быть как минимум в режиме совместимости с vSphere.
Не презентуйте LUN, которые используются как кластерные VMDK, для хостов ESXi версий ниже 7.0.
Не комбинируйте датасторы для clustered и non-clustered VMDK на одном общем кластерном хранилище.
Выделяйте один датастор на один кластер WSFC, не шарьте один датастор между несколькими инстансами кластеров WSFC.
Максимумы конфигураций для таких кластеров WSFC следующие:
Надо помнить еще о следующих ограничениях (более подробно тут):
Конфигурация Cluster in a Box (CIB) не поддерживается. То есть надо настроить правила anti-affinity DRS Rules, чтобы разделить узлы кластера / виртуальные машины по разным хостам ESXi. Если вы попробуете такую ВМ с помощью vMotion переместить, то миграция завершится неудачно.
Горячее расширение VMDK кластерной ВМ не поддерживается.
Не поддерживается Storage vMotion и снапшоты.
VMFS 5 и более ранние версии не поддерживаются.
Таги: VMware, vSphere, WSFC, MSCS, ESXi, VMDK, Storage, Microsoft
Администраторы VMware vSphere в больших инфраструктурах иногда используют кластеры Windows Server Failover Clusters (WSFC) на базе RDM-дисков, которые доступны для хостов VMware ESXi. Ранее они назывались Microsoft Cluster Service (MSCS). При использовании таких кластеров время загрузки хоста ESXi может вырасти аж до целого часа, если не поставить этим LUN статус Perennially reserved.
Суть проблемы в том, что WSFC ставит SCSI-3 reservations для своих LUN, используемых активным узлом, и если ESXi видит эти тома (то есть они не отмаскированы для него), то он безуспешно пытается получить к ним доступ. Для этого он делает несколько попыток при загрузке, пока не решает перейти к следующим томам. Статус этих операций вы можете увидеть, если нажмете Alt+F12 при загрузке хоста:
Xavier Avrillier написал статью о том, как с помощью esxicli/PowerCLI пометить такие тома как Perennially reserved, чтобы ESXi пропускал их при сканировании (об этом также рассказано в KB 1016106).
Сначала вам надо узнать LUN canonical name устройства. Делается это следующей командой PowerCLI:
На сайте virten.net, как обычно, вышла замечательная статья о реальной боли некоторых администраторов VMware vSphere - уменьшении дисков vCenter Server Appliance (vCSA). Так как vCSA работает в виртуальной машине, то иногда возникает необходимость в уменьшении ее дисков в целях простоты перемещения и компактности хранения. Но основная ситуация, когда диски vCSA чрезмерно разрастаются - это апгрейд сервера vCenter - в этом случае его хранилище может увеличиться до 1 ТБ при реально занятом пространстве в 100 ГБ. Тут уже без шринка (shrink) не обойтись.
При апгрейде vCSA установщик смотрит на аллоцированное пространство, а не на занятое, поэтому исходная машина в 416 ГБ может быть преобразована только в целевую ВМ типа Small с 480 ГБ диска:
Метод, описанный ниже, стоит применять только для виртуального модуля vCSA, который вы планируете апгрейдить, поскольку меняется порядок его дисков. Это, в целом, не проблема, но могут возникнуть сложности при взаимодействии с поддержкой VMware, которая может посчитать эту конфигурацию неприемлемой.
Перво-наперво нужно сделать бэкап вашего vCSA или его клон, с которым вы и будете работать. Если что-то не получится, вы просто сможете удалить клон.
Итак, заходим на vCSA по SSH и останавливаем все службы:
# service-control --stop --all
Выбираем файловую систему, для которой будем делать shrink. Например, /storage/seat имеет размер 296 ГБ, но реально используется 67 МБ! Запоминаем файловую систему (/dev/mapper/seat_vg-seat) и точку монтирования хранилища (/storage/seat), которое будем уменьшать.
Также из файловой системы вы можете получить Volume Group (seat_vg) и Logical Volume (seat):
Когда миграция будет закончена, sdh должен остаться пустым (Allocated PE = 0 и нет физических сегментов, только FREE):
# pvdisplay -m /dev/sdh
--- Physical volume ---
PV Name /dev/sdh
VG Name seat_vg
PV Size 300.00 GiB / not usable 7.00 MiB
Allocatable yes
PE Size 8.00 MiB
Total PE 38399
Free PE 38399
Allocated PE 0
PV UUID V7lkDg-Fxyr-qX4x-d3oi-KhNO-XZyT-EHgibI
--- Physical Segments ---
Physical extent 0 to 38398:
FREE
Удаляем sdh из Volume Group:
# vgreduce seat_vg /dev/sdh
Удаляем LVM-метки из sdh:
# pvremove /dev/sdh
Запускаем скрипт autogrow.sh для расширения файловой системы к размеру виртуального диска:
/usr/lib/applmgmt/support/scripts/autogrow.sh
Последний шаг очень важен - удаляем старый диск. Не удалите не тот! Для этого проверяем SCSI ID с помощью lsscsi:
# lsscsi |grep sdh
[2:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh
Мы видим, что SCSI ID [2:0:8:0] нам нужно удалить. Помните, что номер диска не всегда совпадает с SCSI ID. Удалите правильный диск (в данном случае 8), не ошибитесь!
Это все, теперь можно перезагрузить виртуальную машину, после чего в качестве опции апгрейда будет доступен вариант апгрейда на Tiny:
Если вы хотите уменьшить другие разделы, то идентифицируйте соответствующие параметры Logical Volume, Volume Group и Virtual Disk, после чего повторите процедуру.
# lsscsi
[0:0:0:0] cd/dvd NECVMWar VMware IDE CDR00 1.00 /dev/sr0
[2:0:0:0] disk VMware Virtual disk 1.0 /dev/sda
[2:0:1:0] disk VMware Virtual disk 1.0 /dev/sdb
[2:0:2:0] disk VMware Virtual disk 1.0 /dev/sdc
[2:0:3:0] disk VMware Virtual disk 1.0 /dev/sdd
[2:0:4:0] disk VMware Virtual disk 1.0 /dev/sde
[2:0:5:0] disk VMware Virtual disk 1.0 /dev/sdf
[2:0:6:0] disk VMware Virtual disk 1.0 /dev/sdg
[2:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh
[2:0:9:0] disk VMware Virtual disk 1.0 /dev/sdi
[2:0:10:0] disk VMware Virtual disk 1.0 /dev/sdj
[2:0:11:0] disk VMware Virtual disk 1.0 /dev/sdk
[2:0:12:0] disk VMware Virtual disk 1.0 /dev/sdl
[2:0:13:0] disk VMware Virtual disk 1.0 /dev/sdm
Компания VMware опубликовала полезный FAQ, ссылка на который может в любой момент понадобиться администратору VMware vSphere для понимания различных аспектов системного хранилища серверов VMware ESXi.
Давайте посмотрим, на какие вопросы там можно найти ответы:
Что изменилось в системном хранилище ESXi 7 по сравнению с прошлыми версиями? Мы об этом подробно писали тут.
Что случится с разметкой системного хранилища при апгрейде на vSphere 7? Ответ тут и на этой картинке:
Какое хранилище рекомендуется в качестве системного для ESXi?
Что насчет устройств USB/SD? Можно ли использовать SD-карту для системного хранилища? (Спойлер: лучше не надо).
Почему вы можете увидеть ситуацию, что хосты ESXi в "Degraded Mode"?
Что вообще означает Degraded Mode?
Можно ли добавлять локальное хранилище после апгрейда на ESXi 7? (Спойлер: да)
Что делать, если хост в Degraded Mode, а хранилища вообще не видно? (Спойлер: смотреть External Syslog, NetDump Collector или Core Dump Partition)
Если вы используете vSphere AutoDeploy, то как работает развертывание системного хранилища? Подробнее об этом вот тут
Некоторое время назад мы писали об улучшении технологии горячей миграции vMotion (тут и тут) в последней версии VMware vSphere 7 Update 1. Сегодня мы вкратце расскажем о вариантах переноса рабочих нагрузок в кластер хранилищ VMware vSAN на базе вот этой заметки.
Первое, что вы должны решить - это в каком рабочем процессе вы будете мигрировать виртуальные машины с помощью vMotion: за один шаг (хранилище+сервер) или за два (сначала сервер, потом хранилище).
1. Миграция в два шага (Two-Step Migrations)
При выборе миграции виртуальной машины у нас есть опция изменения либо сервера ESXi машины, либо ее хранилища, либо и того, и другого:
Change compute resource only - это первый шаг миграции для случая, когда не-vSAN хранилище может быть презентовано существующему кластеру vSAN. Также это может быть востребовано в рамках топологии VMware vSAN HCI Mesh, где хранилище монтируется удаленному кластеру vSAN.
Change storage only - это второй шаг миграции, когда машина на хосте ESXi уже находится в кластере vSAN, и мы выполняем перенос ее VMDK уже на собственные хранилища кластера.
Надо сказать, что миграция машин в два шага имеет бОльшую гранулярность, что позволит вам получить промежуточный результат и зафиксировать результат в середине (например, смигрированная на другой хост, но не хранилище машина), что может сэкономить время при повторной попытке миграции в случае каких-то проблем.
2. Миграция в один шаг
Этот способ миграции реализуется, когда вы выбираете опцию Change both compute resource and storage или Cross vCenter Server export. Надо понимать, что процесс этот весьма затратный, и выбирать этот вариант можно, когда у вас есть большой запас по ресурсам и времени для вычислительных ресурсов и ресурсов хранилищ. Ну или когда вы не можете расшарить хранилище между двумя разными кластерами vSphere / vSAN.
Удобство это способа еще и в том, что если у вас есть много времени на миграцию, то можно просто поставить vMotion для нужных нагрузок, и все будет постепенно переезжать без участия администратора.
Также для переноса нагрузок между разными инфраструктурами есть опция Cross vCenter Server export. В обновлении VMware vSphere 7 Update 1c главным нововведением стала интеграция функций миграции Advanced Cross vCenter Server vMotion Capability (ранее это был виртуальный модуль Cross vCenter Workload Migration Utility) в интерфейс vSphere Client. Оно же называется XVM.
Эта функциональность используется для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). При этом не требуется настроенного механизма Enhanced Linked Mode (ELM) или Hybrid Linked Mode (HLM) для серверов vCenter в разных датацентрах.
Если вы решили сделать пакетную миграцию виртуальных машин в vSphere Client, то нужно для кластера или пула ресурсов перейти на вкладку VMs и с шифтом выбрать группу ВМ для миграции, после чего из контекстного меню выбрать Migrate...:
Надо сказать, что машины одной группы можно мигрировать только в одинаковом состоянии (Powered on или Powered off), поэтому удобно отсортировать их по колонке State.
Ну и в заключение - картинка об улучшении технологии vMotion с момента ее появления в 2003 году:
Это гостевой пост нашего спонсора - компании ИТ-ГРАД, предоставляющей в аренду виртуальные машины из облака. Магнитная лента, которая фактически является одним из самых архаичных носителей, недавно получила масштабное обновление. Под катом поговорим о продукте, обсудим технические характеристики и возможную применимость в дата-центрах России и мира.
Не все администраторы VMware vSphere и vSAN знают, что в версии vSAN 6.7 Update 3 появилась утилита vsantop, которая по аналогии с esxtop, используемой для получения метрик с хостов ESXi, позволяет получать метрики с устройств и хранилищ vSAN.
Запускается утилита просто: vsantop
По умолчанию она отображает метрики для сущности host-domclient. Чтобы выбрать нужную вам сущность - устройства, хост или кластер, нужно нажать большую клавишу <E> с шифтом:
После того, как вы выберете нужную сущность, будут отображаться метрики для нее с дефолтными колонками в данной категории. Чтобы выбрать колонки, нужно нажать клавишу <f>:
Для отображения можно выбрать только 10 полей, если хотите добавить какое-то поле, то какое-то из текущих придется убрать.
Также esxtop может работать в пакетном режиме с заданным интервалом и записывать метрики в CSV-файл:
vsantop -b -d [delay] -n [iterations] > [file location & name]
usage: vsantop [-h] [-v] [-b] [-d delay] [-n iterations]
-h prints this help menu.
-v prints version.
-b enables batch mode.
-d sets the delay between updates in seconds.
-n runs vsantop for only n iterations. Use "-n infinity" to run forever.
Например, вот такая команда запустит сбор метрик с 10-секундным интервалом, всего будет 20 таких итераций, а результаты будут записаны в файл CSV:
Многие администраторы решения для создания отказоустойчивых хранилищ VMware vSAN иногда задумываются, чем отличаются политики хранилищ виртуальных машин (Storage Policies) для растянутых кластеров в плане Disaster Tolerance.
Дункан Эппинг написал об этом полезную заметку. Если вы не хотите, чтобы ваша виртуальная машина участвовала в растянутом кластере, то вам следует выбрать один из двух вариантов для настройки Site Disaster Tolerance: хранить все данные на основном сайте или все на резервном:
None – Keep data on preferred (stretched cluster)
None – Keep data on non-preferred (stretched cluster)
Между тем, в интерфейсе есть несколько схожих вариантов:
Например, есть еще два, казалось бы, подходящих:
None – Stretched Cluster
None – Standard Cluster
Но оба этих варианта политик хранилищ для растянутых кластеров не подходят. В первом случае (None – Stretched Cluster) виртуальная машина будет обрабатываться на уровне дисковых объектов, и vSAN будет решать, куда их поместить в растянутом кластере. Вполне может получиться такая ситуация, что один VMDK находится на одной площадке, а второй - на другой. При этом сама машина же может исполняться только на одном ESXi:
Такая ситуация очевидно очень плоха с точки зрения производительности.
Во втором же случае (None – Standard Cluster), если ваша машина настроена с точки зрения хранилищ на RAID-1 и FTT=1, то в растянутом кластере это превращается в SFTT=0 (Stretched FTT), что означает, что данные с одной площадки будут зеркалироваться на другую, но на уровне одной площадки будет храниться только одна копия данных дисковых объектов, что плохо с точки зрения надежности и отказоустойчивости.
Поэтому в растянутых кластерах для машин, которым не нужна "растянутость", используйте настройки Keep data on preferred или Keep data on non-preferred.
Если вы когда-нибудь изучали вопрос, почему дискета в 1.44 МБ дает на самом деле 1.38 МБ дискового пространства, то знаете, что это происходит потому, что мегабайт производителей дискет равен 1024х1000 байт. Поэтому дискета на «1,44 Мб» на самом деле имеет ёмкость в 1,44х1024х1000 байт = 1440 Кб или 1.38 Мб (где 1 Мб = 1024х1024 байт). Подробнее об этом вы можете прочитать вот тут.
"Неправильные" килобайты и мегабайты используют префиксы системы СИ (кило, мега, гига), что сложилось исторически, но неверно по сути. "Правильные" (бинарные) килобайты, мегабайты и гигабайты называются кибибайтами, мебибайтами и гибибайтами, соответственно - эти префиксы определены стандартом IEC. При написании они выглядят как KiB, MiB, GiB, TiB и т.д.
Из-за путаницы (или сознательного преуменьшения) производителей систем хранения данных и операционных систем на сегодняшний день иногда трудно понять, какой объем дискового пространства доступен в байтах и не является ли 1 ТБ емкости на самом деле 931 гигабайтом. Например, Microsoft по-прежнему использует систему СИ для отображения мегабайтов/гигабайтов.
VMware приступила к прояснению этого вопроса, начав со своей облачной инфраструктуры VMware Cloud on AWS. Теперь для отображения доступной емкости в консоли используется бинарная нотация IEC:
В данном случае емкость равно 20.74 тебибайта, что в байтах равняется:
Это не изменяли в vCenter, чтобы не вводить пользователей в заблуждение - ведь гостевые ОС отображают данные о емкости в системе СИ. Но имейте в виду, что из-за этого вы можете видеть разные емкости внутри и снаружи ОС при отображении общего и свободного пространства.
Первый момент - это то, что вам не потребуется Storage Replication Adapter (SRA), чтобы использовать репликацию на уровне дискового массива. Тома VVols изначально поддерживают управление хранилищами и их репликацией за счет механизма Storage Policy-Based Management (SPBM). Когда вы настраиваете репликацию VVols, она устанавливается не на уровне LUN, а на уровне виртуальных машин.
Все это упрощает управление репликацией виртуальных машин (нет необходимости настройки и обслуживания SRA), а также повышает гранулярность управления за счет оперирования на уровне отдельных виртуальных машин, а не всего LUN в рамках настройки SRM Protection Groups:
Второй важный момент - это то, что поскольку репликация VVols происходит на уровне виртуальных машин и их хранилищ, то ввиду меньшей гранулярности ВМ можно параллельно реплицировать на разные хранилища в соответствии с политиками SPBM, но при этом с разной периодичностью в зависимости от места назначения и их Protection Groups:
В традиционной инфраструктуре хранилищ, когда вы делаете тест восстановления хранилищ в SRM, то он должен выполняться для целой Protection Group, что рождает определенные сложности и условия при подготовке к тестированию. Для томов VVols все происходит гораздо проще, с учетом разной частоты репликации для виртуальных машин и большей гранулярности тестирования. Также это дает возможности простого восстановления отдельной ВМ в случае сбоя.
Между тем есть некоторые ограничения использования томов VVols и SRM:
SRM не поддерживает защиту виртуальных машин, которые имеют нереплицируемые виртуальные диски.
SRM не поддерживает защиту виртуальных машин с разными дисками на базе VVols, которые имеют разные политики хранилищ с точки зрения репликации и разные replication groups.
vVols не поддерживают восстановление шаблонов виртуальных машин (templates).
VVols поддерживает применение разных политик SPBM к дискам виртуальной машины, но чтобы эта ВМ поддерживалась со стороны SRM, нужно, чтобы все ее диски были настроены на базе одной политики:
Тома vVols 2 с поддержкой репликации уже поддерживаются на стороне хранилищ Dell EMC (PowerMax), HPE и Pure Storage. Также в ближайшем будущем ожидается существенное расширение этого списка.
Более подробную информацию вы можете получить по следующим ссылкам:
На днях компания VMware выпустила обновление своего пакета vRealize Operations Management Pack for Kubernetes 1.5.1, которое позволяет отслеживать состояние контейнерных сред Kubernetes из консоли Operations. Напомним, что ранее оно называлось Management Pack for Container Monitoring.
Надо отметить, что vRealize Operations с помощью данного пакета может обеспечивать мониторинг как сред Tanzu Kubernetes в публичном или онпремизном облаке, так и инфраструктуры OpenStack с развернутыми кластерами Kubernetes.
Давайте посмотрим, что появилось нового в MP for Kubernetes 1.5.1:
1. Поддержка vRealize Operations Advanced
Теперь пользователи издания Advanced также могут использовать пакет управления, ранее эта возможность была доступна только владельцам лицензий Enterprise. Для vRealize Operations Cloud поддержка также сохранилась.
2. Улучшенный сбор метрик средствами Prometheus
Многие пользователи сред Kubernetes используют Prometheus для сбора метрик в кластерах. Теперь vRealize Operations за счет MP может запрашивать метрики с сервера Prometheus, а данные об инфраструктуре получать напрямую через Kubelet API.
Такая интеграция по-прежнему позволит вам использовать механизмы интеллектуального анализа данных, в том числе Troubleshooting Workbench и Metric Correlation.
Prometheus хранит данные в отличном от vRealize Operations формате. Чтобы преобразовать и получить данные для метрик Prometheus можно использовать следующих экспортеров (exporters):
Если ваша команда разработки дорабатывает какие-то метрики в экспортерах, то они автоматически становятся доступны в vRealize Operations.
vRealize Operations также собирает метки (labels) с серверов Prometheus. Они могут включать важные данные, такие как IP-адреса узлов, имена приложений или процессов, номера версий или даже, например, какие метрики используются для конкретного ядра CPU:
Для игнорирования ненужных метрик (например, GUID) можно использовать фильтры:
3. Мониторинг приложений в Kubernetes
Теперь интеграция vRealize Operations и Prometheus позволяет более глубоко взглянуть на уровень приложений:
В данном примере показано приложение Redis, для которого используется экспортер Telegraf. Для него vRealize Operations может видеть такие метрики как: число клиентов, как много времени CPU требуется на выполнение вызовов, информацию о памяти и application backlogs.
4. Поддержка новых Tanzu Mission Control API
Теперь vRealize Operations и MP могут не только автоматически мониторить облачные среды Tanzu Mission Control на платформе AWS, но и полностью поддерживают обновленный API. Также недавно было анонсировано, что Tanzu Mission Control будет поддерживать Tanzu Kubernetes Grid on vSphere 7, и вскоре эта поддержка будет добавлена и в Management Pack.
Скачать VMware vRealize Operations Management Pack for Kubernetes 1.5.1 можно по этой ссылке. Документация находится здесь.
Компания VMware запустила новый ресурс core.vmware.com, посвященный технической информации для администраторов инфраструктуры VMware vSphere, решений vSAN, Horizon, vRealize и других платформ.
На новый портал переехал контент с ресурсов Storage Hub и vSphere Central, который был актуализован и теперь будет регулярно пополняться технической информацией в виде документов и видео.
Документов будет много, но основной упор будет делаться на продукты vSphere, vSAN и Cloud Foundation.
Кстати, раз уж речь зашла о документации, расскажем, что VMware потихоньку начинает добавлять техническую документацию по продуктам на русском языке на сайт VMware Docs (мы писали об этом тут). Смотрите, например, что уже есть по vRealize Automation:
Напомним, что NVMe-oF - это реализация технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP. Для всего этого нужна поддержка RDMA со стороны HBA-адаптера хоста ESXi.
Поддержка NVMe-oF для доступа к хранилищам появилась еще в VMware vSphere 7, а в обновлении Update 1 была улучшена и оптимизирована. В указанном выше документе рассматривается сравнение производительности традиционного протокола Fibre Channel Protocol (SCSI FCP) с реализацией FC-NVMe в vSphere 7.0 U1.
Для всех бенчмарков использовался тот же HBA-адаптер и инфраструктура сети хранения данных SAN. Для генерации нагрузки использовались утилиты fio (для создания разных по размеру операций ввода-вывода I/O, а также паттернов нагрузки) и Microsoft CDB (бенчмарк для генерации OLTP-нагрузки в SQL Server).
Результат оказался весьма интересным. С точки зрения IOPS протокол NVMe-oF смог выжать почти в два раза больше операций ввода-вывода практически для IO любого размера:
Задержка (Latency) также снизилась практически в два раза:
На картинке ниже приведены результаты теста Microsoft CDB для базы данных в числе транзакций в секунду:
Здесь также виден значительный прирост для NVMe-oF, а для двух виртуальных машин производительность выше почти в раза!
Остальные интересные детали тестирования - в документе.
Многие администраторы уже используют продукт VMware vSAN 7 Update 1 для создания отказоустойчивых кластеров хранилищ на базе серверов ESXi. Некоторое время назад мы писали про технологию Cloud Native Storage (CNS), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.
Давайте посмотрим, что нового появилось в возможностях CNS в обновлении vSAN 7 U1:
1. Расширение томов PersistentVolumeClaim
В Kubernetes v1.11 появились функции расширения томов за счет изменения объекта PersistentVolumeClaim (пока только офлайн). Помните, что уменьшение тома (shrink) не поддерживается.
2. Статический провижининг в Supervisor Cluster
Эта возможность позволяет презентовать существующий том в кластере K8s, который будет интегрирован с vSphere Hypervisor Cluster (он же Supervisor Cluster, vSphere with K8s, Project Pacific).
3. Поддержка vVols для vSphere K8s и TKG Service
Теперь обеспечивается поддержка внешних хранилищ на базе vK8s и TKG с использованием томов vVols.
4. Функции Data Protection for Modern Applications
В vSphere 7.0 U1 появились функции поддержки резервного копирования Dell PowerProtect и Velero для Pacific Supervisor и TKG кластеров. Для Velero вы можете инициировать создание снапшотов через Velero plugin и хранить их в облаке S3.
5. Функции vSAN Direct
Возможность vSAN Direct позволяет использовать Direct Attach Storage (обычно на базе физических HDD-дисков) для хранения виртуальных машин VMware vSphere.
Вы можете создавать vSAN Direct Datastores, которые не являются общими для кластера датасторами, но физические диски таких хранилищ можно, например, напрямую подключать к виртуальным модулям (Virtual Appliances) или к контейнерам, исполняемым в среде vSphere, которым нужно объектное хранилище, но при этом хочется использовать его напрямую, минуя стандартный путь данных vSAN.
Мы уже много писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1. Сегодня мы посмотрим подробнее, что нового появилось в плане механики резервного копирования виртуальных машин (Data Protection), реализуемой через VMware vStorage API for Data Protection.
1. Функции Network QoS для трафика резервного копирования
Теперь возможности приоритезации трафика Network QoS доступны и для трафика резервного копирования виртуальных машин. Настроить это можно в vSphere Client в разделе System Traffic > Configure > Edit:
Основное назначение данной настройки - дать возможность урезать полосу канала резервного копирования таким образом, чтобы это не влияло существенным образом на трафик производственной среды.
2. Улучшенная обработка задач резервного копирования
Теперь при входе хоста ESXi в режим обслуживания во время резервного копирования есть флаг Entering Maintenance Mode (EMM), что означает, что операции бэкапа должны переключиться на другой хост ESXi, где сессия NFC (network file copy) может быть продолжена. Это автоматическое переключение происходит прозрачно для задачи резервного копирования, но требует от ПО для бэкапа поддержки данного флага, чтобы обнаружить момент переключения.
3.Улучшенное масштабирование для одновременно запущенных задач РК
Для окружений, где параллельно запущено множество задач резервного копирования, ограничения сервера vCenter могут стать проблемой. Использование сервиса VPXA не позволяет кастомизировать буфер памяти для задач, обрабатываемых через vCenter. В апдейте vCenter Server 7.0 U1 теперь можно настраивать буфер памяти, чтобы обрабатывать множество потоков резервного копирования. Например, для 50 одновременных бэкапов нужно использовать 96 MБ памяти.
4. Улучшения vSphere APIs for I/O Filtering (VAIO)
Фреймворк VAIO - это основной интерфейс для партнерских решений, которые могут перехватывать запросы ввода-вывода операционной системы к виртуальному диску. В этом случае команда ввода-вывода (I/O) не будет применена к диску без прохождения через IO Filter, созданный сторонним ПО.
Теперь здесь появились следующие улучшения:
CIM provider теперь стал 64-битным
Сами VAIO-фильтры теперь будут распространяться как компоненты, а не VIB-пакеты
Напомним, что в vSphere 7 появилась концепция компонентов вместо отдельных VIB-пакетов. В vSphere 7 компоненты - это набор VIB-пакетов, которые может использовать Lifecycle Manager, чтобы накатывать патчи. Теперь компоненты можно накатывать через esxcli с использованием команды component apply.
На сайте virten.net (клевый, кстати, ресурс) появилось описание серьезной ошибки файловой системы VMware VMFS 6, которая используется для создания датасторов в ESXi 7.0 (Build 15843807) и 7.0b (Build 16324942). Он касается кучи ФС (VMFS heap), которая переполняется из-за некорректной работы механизма ее очистки. В VMware vSphere 7 Update 1 эта ситуация решена. Сама проблема описана в KB 80188.
Симптомы переполнения кучи, как правило, следующие:
Датасторы на хостах показывают статус "Not consumed"
Виртуальные машины не могут выполнить vMotion
Виртуальные машины "сиротеют" (переходят в статус "orphaned") при выключении
При создании снапшота возникает ошибка "An error occurred while saving the snapshot: Error."
В логе vmkernel.log могут появляться следующие сообщения об ошибках:
Heap vmfs3 already at its maximum size. Cannot expand
Heap vmfs3: Maximum allowed growth (#) too small for size (#)
Failed to initialize VMFS distributed locking on volume #: Out of memory
Failed to get object 28 type 1 uuid # FD 0 gen 0: Out of memory
Память для кучи VMFS принудительно очищается при аллокации ресурсов файловой системы, например, обычных thick-дисков. Поэтому воркэраунд получается следующий - нужно создать диск Eager zeroed thick на всех смонтированных к хостам ESXi датасторах. Делается это командой:
Проблема только в том, что нужно выполнить эту операцию на каждом датасторе каждого хоста. Поэтому есть вот такая команда для всех датасторов и хостов:
# for I in $(esxcli storage filesystem list |grep 'VMFS-6' |awk '{print $1}'); do vmkfstools -c 10M -d eagerzeroedthick $I/eztDisk;echo "Removing disk $I/eztDisk"; vmkfstools -U $I/eztDisk; done
Результат будет примерно таким:
Сейчас какого-то отдельного патча для решения этой проблемы нет, поэтому нужно самостоятельно следить за поведением инфраструктуры. Основным симптомом является появление в vmkernel.log следующего сообщения:
Maximum allowed growth * too small for size
Если у вас есть такой продукт, как VMware Log Insight, то вы можете настроить аларм на появление этого сообщения в логе.
RSS
